…tAddrV6`

The following methods are made unstable const under the `const_socketaddr` feature:

`SocketAddr`
 - `ip`
 - `port`
 - `is_ipv4`
 - `is_ipv6`

`SocketAddrV4`
 - `ip`
 - `port`

`SocketAddrV6`
 - `ip`
 - `port`
 - `flowinfo`
 - `scope_id`

These are currently documented in the API guidelines:

https://rust-lang.github.io/api-guidelines/interoperability.html#error-types-are-meaningful-and-well-behaved-c-good-err

I think it makes sense to uplift this guideline (in a milder form) into
std docs. Printing and producing errors is something that even
non-expert users do frequently, so it is useful to give at least some
indication of what a typical error message looks like.

Only public items are monomorphization roots. This can be confirmed by noting that this program compiles:
```rust
fn foo<T>() { if true { foo::<Option<T>>() } }
fn bar() { foo::<()>() }
```

This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.

When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.

Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.

To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.

With the addition of a new ABI, this enables rustc to:

* Eventually remove the "wasm-bindgen compat hack". Once this
  ABI is stable wasm-bindgen can switch to using it everywhere.
  Afterwards the wasm32-unknown-unknown target can have its default ABI
  updated to match C.

* Expose the ability to precisely match an ABI signature for a
  WebAssembly function, regardless of what the C ABI that clang chooses
  turns out to be.

* Continue to evolve the definition of the default C ABI to match what
  clang does on all targets, since the purpose of that ABI will be
  explicitly matching C rather than generating particular function
  imports/exports.

Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.

A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.

See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170

Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.

It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!

Constify methods of `std::net::SocketAddr`, `SocketAddrV4` and `SocketAddrV6`

The following methods are made unstable const under the `const_socketaddr` feature (rust-lang#82485):

```rust
// std::net

impl SocketAddr {
    pub const fn ip(&self) -> IpAddr;
    pub const fn port(&self) -> u16;
    pub const fn is_ipv4(&self) -> bool;
    pub const fn is_ipv6(&self) -> bool;
}

impl SocketAddrV4 {
    pub const fn ip(&self) -> IpAddr;
    pub const fn port(&self) -> u16;
}

impl SocketAddrV6 {
    pub const fn ip(&self) -> IpAddr;
    pub const fn port(&self) -> u16;
    pub const fn flowinfo(&self) -> u32;
    pub const fn scope_id(&self) -> u32;
}
```

Note: `SocketAddrV4::ip` and `SocketAddrV6::ip` use pointer casting and depend on the unstable feature `const_raw_ptr_deref`

Avoid sorting by DefId for `necessary_variants()`

Follow-up to rust-lang#83074. Originally I tried removing `impl Ord for DefId` but that hit *lots* of errors 😅 so I thought I would start with easy things.

I am not sure whether this could actually cause invalid query results, but this is used from `MarkSymbolVisitor::visit_arm` so it's at least feasible.

r? ``@Aaron1011``

…=nagisa

rustc: Add a new `wasm` ABI

This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.

When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.

Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.

To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.

With the addition of a new ABI, this enables rustc to:

* Eventually remove the "wasm-bindgen compat hack". Once this multivalue
  ABI is stable wasm-bindgen can switch to using it everywhere.
  Afterwards the wasm32-unknown-unknown target can have its default ABI
  updated to match C.

* Expose the ability to precisely match an ABI signature for a
  WebAssembly function, regardless of what the C ABI that clang chooses
  turns out to be.

* Continue to evolve the definition of the default C ABI to match what
  clang does on all targets, since the purpose of that ABI will be
  explicitly matching C rather than generating particular function
  imports/exports.

Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.

…andry

Translate counters from Rust 1-based to LLVM 0-based counter ids

A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.

See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170

Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.

It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!

r? `@tmandry`
FYI: `@wesleywiser`

Document "standard" conventions for error messages

These are currently documented in the API guidelines:

https://rust-lang.github.io/api-guidelines/interoperability.html#error-types-are-meaningful-and-well-behaved-c-good-err

I think it makes sense to uplift this guideline (in a milder form) into
std docs. Printing and producing errors is something that even
non-expert users do frequently, so it is useful to give at least some
indication of what a typical error message looks like.

Monomorphization doc fix

Only public items are monomorphization roots. This can be confirmed by noting that this program compiles:
```rust
fn foo<T>() { if true { foo::<Option<T>>() } }
fn bar() { foo::<()>() }
```
See also the [zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Why.20are.20non.20public.20items.20monomorphization.20roots.3F).